Now that I sent an update about my running activities, I have to report about what I'm doing these weeks in Debian to try keeping a fair balance for those of you who read this blog through Planet Debian. Most January was spent in preparing the release of squeeze. Of course, I didn't work directly on the release, not being involved in the release team. However, last bits of preparation for Debian Installer as well as rushing out the last remaining bits of localization work took most of my time. After the release of squeeze, time came to resume back some activities. First of all, on the l10n front, I resumed the work on "l10n NMUs", trying to get old l10n bugs fixed. I restarted proposing NMUs or, more precisely, help to perform translation updates rounds to these maintainers. Most of them had "old" l10n bugs because of the freeze. So, I indeed did not end up in doing many NMUs...but got several l10n bugs closed anyway. Work being resumed in unstable also lead to many changes in packages' debconf templates (new packages using debconf, packages introducing new templates, etc.). As these are the trigger for Smith reviews (reviews of English in debconf templates and packages' description, this activity, which was very low during the freeze, resumed again (we'll soon celebrate the 4th anniversary of this project). I also decided to invest more time in D-I again. The D-I team is currently more active than it was last years. Thanks to a few individual, work resumed in some areas and bug triaging has been very active. I recently resyned a nice improvement which had been contributed by a user to iso-scan, then polished by Frans Pop. This will allow to choose among several different ISO images when installing Debian from a USB stick while, previously, only the first found was being used. I also worked with a new translator, to prepare the activation of Uyghur translation in D-I. Some work happend in the pkg-fonts team. I had a few fonts adopted by the team, as part of the general effort to get rid of defoma. I sent patches for a few others, but many remain. If you maintain font packages, please help us in getting rid of defoma. Changes are easy to do; ask the team if you need help (pkg-fonts-devel@lists.alioth.debian.org). Samba packages also ate a significant part of my time. First of all, DSA-2175 lead to prepare fixes for samba in squeeze and lenny. Then, upstream released samba 3.5.8 which I uploaded to unstable. I briefly considered trying to get the Stable Release managers approval to push that version in squeeze, but the number of fixes made by upstream was discouraging. So, I chose to examine them slowly and cherry-pick those I consider important enough to warrant an upload for squeeze. More git wizardry learned doing so (thanks to Julien Cristau for his help). And I now have a pending proposal for three of these fixes (that represent 14 atomic patches from upstream) to be included in squeeze.

Time for a fifth Debian XSF News issue!

• Lintian was tweaked to stop rejecting packages for buggy reasons. The 45 prepared driver packages could be uploaded again, and got accepted, making X installable again in unstable. Plenty of bug reports came along accordingly.
• Julien Cristau uploaded a bunch of packages to unstable (merging stuff prepared in experimental over the last weeks/months, and some new upstream versions): twm, x11-apps, x11-session-utils, x11-utils, x11-xfs-utils, x11-xkb-utils, x11-xserver-utils, xterm, xft, xbacklight.
• He also prepared xorg-server 1.10 for experimental, with Christopher James Halse Rogers. That meant updating randr and xext proto packages. We re currently waiting for 1.10rc2 before uploading to experimental, probably with a restricted set of drivers.
• Thanks to Samuel Thibault s and Pino Toscano s help (and a lot of patience), mesa builds on hurd-i386 again. xorg-server is no longer BD-Uninstallable accordingly. Ditto for kfreebsd-i386, the server was built right after mesa, and all driver packages were built after that.
• In the same mesa upload, I made the bug script report a bit more: it runs glxinfo if available, and the xserver-xorg-core bug script as well. That, together with a report-with: xserver-xorg xserver-xorg-core in the bug control file for each binary package should spare a few mails asking submitters for more info.
• I also uploaded a new libdrm revision, cherry-picking a fix for a bug preventing X to start with some Intel cards. Since we had several reports of run-time issues with older libdrm-intel1 (squeeze s/2.4.21), I bumped symbols/shlibs to make sure packages building against it pick a higher version.
• I uploaded a new xorg-server to unstable with the following changes:
  • The hellish dependency loop (#362313) is finally gone!
  • Since drivers reached unstable, there was no need to keep the virtual packages with both major andminor versions. Those were meant to ease the transition from experimental to unstable, making it possible to install experimental s drivers with unstable s server.
  • The bug script now reports KMS configuration files (/etc/modprobe.d/$driver-kms.conf) and their contents. The lspci call was also updated. Finally, libGL-related diversions are now reported as well.
• Those bug script improvements were cherry-picked in the debian-squeeze branch, which should be finalized next week. This branch also features a bug fix for RandR on nvidia.
• On the documentation side, I started a general FAQ as well as a how to build mesa guide.
• I d like to thank all submitters taking time to report bugs, even more so when they reply quickly with more info. Special thanks to the submitters who forward their bugs upstream, even marking the Debian bugs forwarded accordingly!

Here comes the forth Debian XSF News issue! I usually try to keep the items sorted chronologically (but grouped by topic when possible), so if you re wondering about the current status of X in unstable, make sure you read the last entry.

• I prepared a reference documentation about dependency handling between the X server and the drivers. It describes both upstream and Debian sides, and documents the mechanisms to get the dependencies right. If you maintain an input or a video driver for X, you really should have a look into it.
• I also announced the changes on debian-boot@ since the Graphical Installer is also concerned.
• Since there are some drivers which aren t maintained by the X Strike Force, I mailed almost all maintainers (plus the ones I missed) to keep them posted. Further coordination will go through a mail alias (which means a little less overhead than running a mailing list; mail me if you want to be added).
• I prepared a great clean-up of the drivers, and published a status report 3 days later.
• In order to keep track of people working on X packages these days, I started pinging the Uploaders of X packages. Thanks again, folks!
• On the driver side, I moved the xserver-xorg-video-dove driver to the attic (where we move repositories of unmaintained packages), since it was only ever uploaded to Ubuntu, and not really maintained upstream. I also moved 7 drivers there, and requested their removal through RM bugs (each bug contains a link to the git repository in the attic in case someone wants to revive a driver): xserver-xorg-input-citron, xserver-xorg-input-evtouch, xserver-xorg-input-fpit, xserver-xorg-input-hyperpen, xserver-xorg-video-nv, xserver-xorg-video-radeonhd, xserver-xorg-video-v4l.
• Julien Cristau also requested the removal of xprint and xprint-utils. He also orphaned xresprobe since it s of no use as far as X is concerned, but still seems to be of some interest to DebianEdu folks.
• I requested an update of debian-x@ s description. We haven t been doing any Debian XFree86 packaging in a while.
• I requested help from GNU/kFreeBSD and GNU/Hurd folks, and got replies from Petr Salinger and Dave Airlie. Now mesa builds again on kfreebsd-amd64 (and kfreebsd-i386 once the remaining glitch is fixed).
• In the same mesa upload, I enabled the r600 Gallium driver, and cherry-picked a commit to fix the crash at X s start-up with r300 and UMS.
• I merged the xsf-docs.git repository (source for XSF documentation at http://pkg-xorg.alioth.debian.org/) into the xorg.git one, and moved the former to the attic. Starting with xorg/xserver-xorg 1:7.6+2, XSF documentation is shipped in the xserver-xorg package, in the /usr/share/doc/xorg directory, in HTML, PDF, and TXT formats.
• I also added a bug control file (as documented in reportbug s README.developers) to xorg, telling reportbug to also report information related to the xserver-xorg package. This means we get xserver-xorg-core s version, along with the drivers. I also made xorg depend on xserver-xorg with the same version, to make sure that upgrading xorg means upgrading xserver-xorg as well (and xserver-xorg-core ultimately, since xserver-xorg pulls a given version of the server).
• Julien also uploaded a few libraries and mesa-demos (new source package for mesa-utils) to unstable. I also uploaded the latest pixman to unstable.
• A few hours before squeeze got released, I prepared the big move of the X server from experimental to unstable. For the record that meant uploading libdrm, libxfont, and mesa as prerequisites. I then pushed the locally-built packages in a local archive to use from my sbuild chroot, to get xorg-server built. Subsequently, I built 45 drivers against it. The xorg metapackage was also prepared. All in all, that meant 200MB worth of Debian packages (including 130MB for mesa alone ), which sat on ravel.debian.org until the squeeze release announcement. Unfortunately, lintian s #612137 triggered an automated rejection of all drivers. Options seemed to be: adding build dependency noise to debian/control for all drivers; or adding lintian-overrides noise to all drivers; or waiting for some reaction from lintian s maintainers or from ftpmasters. I picked the last option for now, since I m very reluctant to do extra and pointless work on 45 packages to get them accepted when the reason for the rejection is buggy. Hopefully this will be sorted out soon, and I ll be able to upload the same packages again. If one feels the urge of installing X11R7.6, picking drivers from experimental will do the job.

I've been doing a bit of work recently on the netcfg portion of Debian Installer, with the largest work so far being adding IPv6 support. Unlike most of the rest of d-i, netcfg is written in C, and as such suffers from some difficulties in the realm of debugging. Worse, the whole d-i environment is rather bereft of the usual debugging tools (strace, lsof, etc) -- but most importantly, in this case, gdb. Thanks to some hints from Julien Cristau, I was reminded of the existence of gdbserver, a small part of gdb that allows you to debug a program running on a remote machine, using a copy of gdb running on your local machine. It's designed for debugging embedded systems, I think, because all of the heavy lifting (symbol lookups, etc) happens on your local machine, not where gdbserver is running. Here are the steps I took to get a useful gdbserver session inside d-i:

1. Get the gdb sources (apt-get source gdb) and drop into the gdbserver tree (cd gdb-x.y.z/gdb/gdbserver)
2. Configure gdbserver to build a static binary (LDFLAGS=-static ./configure). This is necessary because you don't want to have to faff around with library dependencies inside the d-i environment. Then build gdbserver (make).
3. Copy gdbserver over to your d-i machine/VM (I like using netcat; nc -l -p 31310 >/bin/gdbserver on the d-i machine, and nc IPADDR 31310 <gdbserver where you built gdbserver), then make it executable (chmod /bin/gdbserver)
4. Fire up gdbserver in d-i, attaching it to the process you wish to debug: gdbserver host:31337 --attach PID
5. Now things get a little trickier... on your local machine, you need to have an unstripped copy of the binary you're debugging. For me, this is easy, because I'm building netcfg myself (to keep the symbols, I just run DEB_BUILD_OPTIONS=noopt dpkg-buildpackage -b -rfakeroot) but I'm not sure what you'd do if you were just tracing around for fun.
6. Once you've got your binary, just run gdb BINARY on your host machine to start gdb running.
7. For the "even trickier" part of the show, your local machine also needs copies of all the libraries your binary is linked against. If you don't have this, when you try to debug you'll get all sorts of "wrong library or version mismatch?" errors, and your backtraces will likely break (amongst other things). Again, for me, this is easy, because I'm only running the d-i initrd, but if you're debugging something later in the installation process you might need to unpack some udebs somewhere. All I have to do is keep the initrd build tree around (which lives in the installer tree, under build/tmp/netboot/tree). Once you've got your tree of libraries, you can continue.
8. You need to tell gdb about that tree of libraries, by running the following in gdb: set solib-absolute-prefix /path/to/library/tree
9. Now, tell gdb to connect to your gdbserver: target remote IPADDR:31337 -- gdb should tell you "Remote debugging using IPADDR:31337", and the gdbserver should say "Remote debugging from host LOCALIP:31337".
10. Now, you should be able to interact with the program being debugged just like any other. Enjoy!

Time for a second Debian XSF News issue! I ll skip stuff related to the new katamari since I wrote about that already.

• I reassigned a big memory leak to the kernel. It happens with a Radeon HD 4200 card and the xserver-xorg-video-ati driver.
• I mentioned on debian-boot@ how to reassign bug to the xorg meta package. We regularly receive bug reports about either X-related issues in the graphical installer, or about the just-installed X stack.
• I started a xsf-docs repository to hold some documentation, trying to keep up-to-date information about the X stack. The wiki is unfortunately a bit of a mess, and contains some very old stuff like an ancient FAQ. This has historical value, but doesn t really help. ;) The new documentation lives at http://pkg-xorg.alioth.debian.org/, and it should be packaged at some point (maybe merged into an existing package).
• Julien Cristau uploaded xorg-server 2:1.7.7-10 to unstable, and it was unblocked for squeeze.
• Triage happened on the xorg meta package, which should be our frontdesk : people should report or reassign bugs against this package when they re not sure which X component is at fault.
• The intel driver was tweaked to fail properly if KMS is disabled, so that the X server autodetection code could fall back to vesa. Unfortunately, it turned out to be insufficient in some cases. That was fixed in the we wish you a working driver release. The latter migrated to squeeze.
• On a related note, we discovered (through bug reports), that the intel driver in experimental somehow needs libdrm-intel1 from experimental. Not that symbols would be missing, but some nasty bugs happen when the version from unstable is used instead. We still need to address this issue.
• Julien pushed more patches to the server-1.7-branch upstream, which I merged, uploaded as 2:1.7.7-11, and got unblocked for squeeze. A crasher was reported right after that, but it s probably going to wait for squeeze r1 (see next entry).
• Bernhard R. Link reported an issue with old XF86Config-4 configuration files. We cloned that bug report and fixed both in git. I ll probably upload xorg-server 2:1.7.7-12 to unstable soon with those fixes. Then we ll probably upload 2:1.7.7-12~squeeze1 to stable-proposed-updates once squeeze is released.
• To keep track of this kind of bugs, I ve started using the squeeze-candidate usertag. That s documented in the how to triage bugs page, added to xsf-docs.
• I updated the cirrus driver to improve support in QEMU and FAUmachine, it s been unblocked for squeeze.
• I fixed partial upgrades for the libx11-6 and libx11-data packages.
• Julien Viard de Galbert has been very active in the bug triaging area! See the reports: TXBW3, TXBW4+5, TXBW6, TXBW7, TXBW8.
• He also blogged about how easy it is to triage X bugs. Join the fun!
• I also wrote a tiny doc about configuring input, and poked a bunch of bugs for the following input drivers: evdev, kbd, mouse, and synaptics.
• I digged into the infamous gdm3 bug, which causes xkb options to be lost when one logs in. A summary is available in the upstream bug report.

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer s job. While it s true in general, some understaffed teams are so flooded by bugs that they just can t do it.
I ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks! Then the thread evolved in lots of directions, I m not following all of it, but there was the question of the bug triaging and as I m doing it for the X packages, I want to share about my experience here. The available triaging docs The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o ! Now if all those docs don t help you, then try to improve the docs as a first step ! Talk with the maintainer(s) Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway. My current process This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!

1. List bug from UDD: XSF unstable bugs sorted by date.
2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
3. Read the report, don t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it s not that often that I have something to test).
5. Decide what to do, most of the time, I will ping the submitter.
6. I m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
   So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
   The triaging procedure suggest to ping -submitter, but using mutt it s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
9. When the submitter answers, just react accordingly, if the bug can be closed, then close it !
10. If after some time, the bug are still not answered, consider closing them (I haven t started that yet, but this will probably get the bug number down faster:) ).

Note: Sometime I don t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. To submitters, please keep the bug CCed when you answer, thanks. For the skeptics Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don t close bugs if I m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! Also this work might look boring, but it s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I ve learned on Xorg. Conclusion As long as I have time for it, I ll continue to triage bugs and I d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! Get involved !

Since people seem to like it, I ll be trying to publish some news about ongoing work on the XSF side, on a (possibly) regular basis. Let s have a look at what happened since last time I blogged about X in Debian, mostly by checking what appeared in my =debian-x mailbox. Debian XSF News #1

• mesa 7.9 was uploaded to experimental by Julien Cristau.
• Jurij Smakov uploaded a bunch of xserver-xorg-sun* drivers to experimental for us.
• I started a debian/xsf-tools.git repository to gather some tools for people wishing to work on X-related packages. For now it contains the usual tagging script, an mrconfig file to ease downloading/updating all XSF packages, thanks to the mr tool, and some bits of documentation. I also added the git URL to the upstream repositories to debian/watch* for all packages.
• Christopher James Halse Rogers started a discussion about the Ubuntu plans for Natty release. This is mostly about DRI, and unfortunately, I haven t digged into mesa yet, but thankfully we had some answers from upstream there.
• I uploaded many xfonts-* packages, prepared by Julien Cristau.
• I uploaded many x11-* bundles as well. Why are we creating bundles? Because there are many tiny applications, which (from the distribution point of view) don t deserve their own package. For example x11-apps contains toys like xclock, xeyes, or xlogo.
• I uploaded many lib* packages, plus pixman. When there were no fundamental changes (as in: no need for an shlibs bump, which could prevent some packages from migrating), those were uploaded to unstable, others went to experimental.
• Some cherry-picked patches were added to libx11, from a stable branch. The 2:1.3.3-4 version has been unblocked for squeeze, and brings support for Compose O A and for Compose \ o /.
• I also reverted the removal of the (famous?) apple:badmap and apple:goodmap options for macintosh keyboards in xkeyboard-configuration (which produces the xkb-data binary package), thanks to a bugreport from Yves-Alexis Perez; it s been unblocked for squeeze as well. If someone notices an inversion of those keys after the upgrade, that s probably because one of those options was added at some point, was ignored and unnoticed, and finally taken into account. Depending on the case, it s sufficient to switch to the other one, or to remove it entirely.
• Many bug submitters were pinged by Julien Viard de Galbert. But another report should appear soon, following TXBW1 and TXBW2.
• More drivers were updated to their latest upstream versions, and uploaded to experimental.
• Thanks to an xserver-xorg-video-mga user (Ferenc W gner), we were able to extract and apply a patch from launchpad s #292214 to fix the dual head breakage. Since we haven t seen any complains since then, we ll probably ask for an unblock for squeeze.

What are the XSF plans?

• Keep close track of upstream work, possibly contributing there. We re mostly up-to-date with the RC1 for X11R7.6 and it d be nice to keep it that way, but that requires time/work.
• Keep on answering new bug reports quickly, before bug reporters vanish or switch to another system (a broken X can trigger this kind of reaction).
• Keep on pinging older bug reports. Anyone is welcome to join and help, there s no high profile required to do so, as confirmed by Julien Viard de Galbert.
• To make it easier, it would be nice to have some documentation written down, instead of relying on everyone s own memory. There s a lot of wiki pages about X in Debian, but they might be outdated, incomplete, or inaccurate. Building up some consistent documentation should help people understand how they can contribute, and how to do so.
• It d be nice to have some documentation targeted at users as well, so refreshing the old XSF FAQ would be welcome, as well as shipping it in some package for offline use.

Hello fellow developers, The summer is over but I m happy to announce that this year s Summer of Code at Debian has been better than ever! This is indeed the 4th time we had the privilege of participating in the Google Summer of Code and each year has been a little different. This year, 8 of our 10 students succeeded in our (very strict!) final evaluations, but we have reasons to believe that they will translate into more long-term developers than ever, all thank to you. The highlight this year has been getting almost all of our students at DebConf10. Thanks again this year to generous Travel Grants from the Google Open Source Team, we managed to fly in 7 of our students (up from 3!). You certainly saw them, presenting during DebianDay, hacking on the grass of Columbia, hacking^Wcheering our Debian Project Leader throwing the inaugural pitch of a professional baseball game or hacking^Wsun-tanning on the tr s kitsch Coney Island beach. Before I give the keyboard to our Students, I d like to tell you that it will be the pleasure and honor of Obey Arthur Liu (yours truly, as Administrator) and Bastian Venthur (as Mentor) to represent Debian at the Summer of Code 2010 Mentors Summit on 23-24 October 2010, at the Google Headquarters in Mountain View. Like last year, we expect many other DDs to be present under other hats. We will be having 2 days of unconference on GSoC and free software related topics. We all look forward to reporting from California on Planet and soc-coordination@l.a.d.o! All of our students had a wonderful experience, even if they couldn t come to DebConf, that is best shared in their own voice, so without further ado, our successful projects: Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt apt-get install MultiArch does mostly work now as most code is already merged in squeeze, but if not complain about us at deity@l.d.o! Still, a lot left on the todo list not only in APT so let us all add MultiArch again to the Release Goals and work hard on squeezing it into wheezy. Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Hello, I m David Wendt, and I went to Debconf10 to learn more about the development side of Debian. Having used it since the 9th grade, I ve been intimately familiar with many of Debian s internals. However, I wanted to see the developers and other Debian users. At DebConf, I was able to see a variety of talks from Debian and Ubuntu developers. I also got to meet with my mentor as well as the maintainer of Debbugs. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont Config::Model is now capable of manipulating files using shorter and easier to write models. Thanks to that, packagers may start experiment with creating upgrade models. Further work is needed to support more complicated config files Dominique Dumont is working on DEP-5 parser, I ll shortly start working on a cupsd config file parser.
The best thing about DebConf10 is that every person I talked with knew what I was doing. I had a mission to get some feedback on my project. Everybody liked the idea of making upgrades less cumbersome. On the other side, it was my first visit to United States, so I decided to go on a daytrip on my own (instead of staying inside the building, despite heat warnings). I had a chance to visit many interesting places like Ground Zero, the UN headquarters, Grand Central Terminal, Times square and Rockefeller Center that was a great experience. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault Debconf10 was great! Among other people working on the installer, I met Aur lien Jarno from the Debian/kFreeBSD team and we worked together on a cross-platform busybox package. Besides, the talks were very interesting and I ve filled my TODO-list for the year.
For instance I learned about the Jigsaw project of OpenJDK, and how Debian would be the ideal platform to experiment with it. More generally, some people think Debian could push Java 7 forward and I d like to see this happen. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert I must say that it was great time for me in NY, I ve met and talked and coded with people from ftp-master team like Torsten Werner who helped me to push the project a bit further and with some other people who were looking forward to release of the tool which I hope they will use quite soon. Everybody interested, everybody excited, really cool place and time. And I can t forget the Coney Island beach and stuff, lot of fun, lot of sun;) Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Currently, development branches support full features searching, viewing extended package s informations, performing cache and packages operations. Code and GUI still require a lot of work which will be continued. Informations about further progress could be found on aptitude mailing list and repository rss channel. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin For me, DebConf 10 started at the airport, where Sylvestre Ledru (whom I didn t know of before) was wearing a GSoC 2007 t-shirt, that is, given the circumstances, almost equivalent to say I m a hacker, I m going to DebConf 10 .
I ve spent my time at the conference attending various talks, hacking, meeting DDs and other hackers (amongst others, my co-mentor Per Andersson, Paul Wise, Julien Cristau, Christian Perrier, Cyril Brulebois, Martin Michlmayr, Colin Watson and Otavio Salvadores who I have to thank for his patience while dealing with my questions), chatting, cross-signing keys, rushing to finish eating before 7pm, getting sunburnt, sightseeing (thanks, Arthur, for the lightning-fast tour of Manhattan!), and so on. Debian Developers and community, we count on you. See you next year! (cross-posted to debian-devel-announce@l.d.o and soc-coordination@l.a.d.o)

Getting to X After having prepared a bunch of libraries, the idea was to get X in shape. I d like to thank Julien Cristau very much for his support all along the way, since I knew nothing about X. Basically the plan was to get:

• xserver-xorg-core-udeb: X itself.
• xserver-xorg-input-evdev-udeb: for input, as you probably guessed.
• xserver-xorg-video-fbdev-udeb: for output, as you also probably guessed.

Not much to say about the former, it only pulled two additional libraries compared to what was previously udeb-ified: libaudit0 and libselinux1. Since security modules aren t the primary concerns in this exercise, --enable-xselinux quickly became --disable-xselinux and those dependencies went away. Both drivers were trivial to tweak, nothing really worth noting there. Once those 3 additional packages added to localudebs/ and to pkg-lists/local, the mklibs tool really wasn t happy with them during the rebuild of the netboot image, since the drivers are X plugins, meaning they need symbols which aren t defined in other libraries. Example:

No library provides non-weak EventSwapVector

Since the idea is to get something working rather than getting something perfect at once, d-i s packages/mklibs/src/mklibs.py (installed as /usr/bin/mklibs) was told to stop raising an exception, and to print a warning message instead. Rebuilding an image was then working again. It took some time, but finally it got noticed those packages were actually all installed in the initramfs, so there was no need to try and load/install them manually during the installation process, everything was there already, and it was sufficient to switch to VT2 to see the /usr/bin/Xorg binary. Some packages were still needed: xkb-data, and x11-xkb-utils. The latter also pulled libxkbfile1, but well, an additional library doesn t sound very scary. At this point, one has to try and run Xorg. The result was a black screen, and no means of getting back to another terminal, be it inside Qemu or VirtualBox. Troubleshooting X First idea: adding the openssh-server-udeb package to the image, and start sshd from there. But then one has to go through the missing config file, tweaking privilege separation, generating a host key, setting a password, etc. And for whatever reasons, it wasn t possible to access it. That s where the DebianInstaller/NetworkConsole page on the Debian Wiki came into play: it includes a few steps to get a working sshd within d-i, painlessly. So, X was actually starting properly, but getting a black screen is now the default. One wants X -retro to get the well-known old behaviour. From udevadm info --export-db, it looked like input stuff were missing, and indeed, udev-udeb doesn t include /lib/dev/input_id and /lib/udev/rules.d/60-persistent-input.rules. Since scp seems broken, wget from the host did the trick followed by chmod +x for the input_id file, otherwise that doesn t work so well. But still, there were some missing evdev stuff. And indeed evdev wasn t to be seen in lsmod, nor available to be modprobe d. That s where it became a little dirtier: wget and udpkg on mouse-modules-2.6.30-2-amd64-di, followed by depmod to make sure, and then modprobe was OK. A little udevadm trigger run to ensure udev was fully aware of the new situation, and restarting X led to a moving cursor there, as well as a working keyboard, since it was possible to switch between terminals! Prove it! Alright, I m proudly providing you with a screenshot: (Really, I ve never been so happy to see this fracking black-and-grey-grid screen. I kid you not!) If we forget about the very few network-console-related questions answered to get an sshd running, please note that the installation process is still just starting, the very first debconf question is still unanswered. Now, patching udev again so that udev-udeb includes the two mentioned files was almost easy (details aren t important anyway), while pulling evdev.ko module automatically was trivial, just a matter of adding such a line to a packages list (I picked pkg-lists/netboot/amd64.cfg):

mouse-modules-$ kernel:Version 

Which means one can now, out of the box:

• Boot the ISO, select Install.
• Wait for the first question to appear.
• Switch to another terminal, and activate it.
• Run Xorg -retro there.

Next step Rework the Pango/Cairo/Gtk stack to use X11 instead of DirectFB.

RCBW - #17 Given that my "most blogged" Debian activity since last summer has been RCBW, what else could be my first post of 2010 if not a RCBW update? With further ado, here are this week squashes by yours truly:

• bug #559898 - flowcanvas - fixed in unstable, tag as needed
• bug #562503 - man-db - downgrading severity (RC-ness was in zlib, which is now fixed)
• bug #541610 - docbook2odf - switch dep away from (now gone) libxml-sablot-perl
• bug #528088 - ttf-aenigma - fonts are actually free, as detailed in debian/copyright
• bug #544113 - tiger - remove dep on essential package (bonus: misc deps/debhelper fixes)
• bug #561466 - ttf-beteckna - rebuild against fixed defoma (thanks Julien Cristau who spotted a wrong fix of mine)
• bug #561470, bug #549987 - halevt - add missing dep on policykit (bonus: QA upload with misc fixes)

No particular remarks, but a long overdue tip of the week: the turmzimmer BTS interface is a great tool for bug squashing. Still, it has a issue with comments which can slow down some activities, but which you can help getting better! First of all you should know that comments are per-package and not per-bug (which might not be obvious, especially since often packages listed on the page have just one bug per-package). That means that you should generally mention the bug you are referring to when you post comments, unless the comments are really package-specific. Additionally, old comments are persistent, so you might get baffled by old comments that "invalidate" current issues. So, if you notice a comment that predates the actual bug numbers, please remove the comment by editing it and stating "no comment" in the form. Ah, happy new year (in case you care about sharp, calendar-based time partitions).

Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

xmodmap has long been the only way to modify the keyboard map of the X server, short of the complex configuration daemon approaches used by the large desktop managers, like KDE and GNOME. But it has always been a hack: it modifies the X keyboard map and thus requires a baseline to work from, kind of like a patch needs the correct context to be applicable. Worse yet, xmodmap weirdness required me to invoke it twice to get the effect I wanted. When the recent upgrade to X.org 7.4 broke larger parts of my elaborate xmodmap configuration, I took the time to finally ditch xmodmap and implement my modifications as proper xkb configuration.

Background information I had tried before to use per-user xkb configuration, but could not find the answers I want. It was somewhat by chance that I found Doug Palmer s Unreliable Guide to XKB configuration at the same time that Julien Cristau and Matthew W. S. Bell provided me the necessary hints on the #xorg/irc.freenode.org IRC channel to get me started. The other resource worth mentioning is Ivan Pascal s collection of XKB documents, which were instrumental in my gaining an understanding of xkb. And just as I am writing this document, Debian s X Strike Force have published their Input Hotplug Guide, which is a nice complement to this very document you are reading right now, since it focuses on auto-configuration of xkb with HAL. The default xkb configuration comes with a lot of flexibility, and often you don t need anything else. But when you do, then this is how to do it:

Installing a new keyboard map The most basic way to install a new keyboard map is using xkbcomp, which can also be used to dump the currently installed map into a file. So, to get a bit of an idea of what we ll be dealing with, please run the following commands:

xkbcomp $DISPLAY xkb.dump
editor xkb.dump
xkbcomp xkb.dump $DISPLAY

The file is complex and large, and it completely went against my aesthetics to simply edit it to have xkb work according to my needs. I sought a way in which I could use as much as possible of the default configuration, and only place self-contained additional snippets in place to do the things I wanted done differently. setxkbmap and rule files Thus began my voyage into the domain of rule files. But before we dive into those, let s take a look at setxkbmap. Despite the trivial invocation of e.g. setxkbmap us to install a standard US-American keyboard map, the command also takes arguments. More specifically, it allows you to specify the following high-level parameters, which determine the sequence of events between key press and an application receiving a KeyPress event:

• Model: the keyboard model, which defines which keys are where
• Layout: the keyboard layout, which defines what the keys actually are
• Variant: slight variantions in the layout
• Options: configurable aspects of keyboard features and possibilities

Thus, with the following command line, I would select a US layout with international (dead) keys for my Thinkpad keyboard, and switch to an alternate symbol group with the windows keys (more on that later):

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch

In many cases, between all combinations of the aforementioned parameters, this is all you ever need. But I wanted more. If you append -print to the above command, it will print the keymap it would install, rather than installing it:

% setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch -print
xkb_keymap  
  xkb_keycodes    include "evdev+aliases(qwerty)"        ;
  xkb_types       include "complete"     ;
  xkb_compat      include "complete"     ;
  xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;
  xkb_geometry    include "thinkpad(us)"         ;
 ;

There are two things to note:

1. The -option grp:win_switch argument has been turned into an additional include group(win_switch) on the xkb_symbols line, just like the model, layout, and variant are responsible for other aspects in the output.
2. The output seems related to what xkbcomp dumped into the xkb.dump file we created earlier. Upon closer inspection, it turns out that the dump file is simply a pre-processed version of the keyboard map, with include instructions exploded.

At this point, it became clear to me that this was the correct way forward, and I started to investigate those points in order. The translation from parameters to an xkb_keymap stanza by setxkbmap is actually governed by a rule file. A rule is nothing more than a set of criteria, and what setxkbmap should do in case they all match. On a Debian system, you can find this file in /usr/share/X11/xkb/rules/evdev, and /usr/share/X11/xkb/rules/evdev.lst is a listing of all available parameter values. The xkb_symbols include line in the above xkb_keymap output is the result of the following rules in the first file, which setxkbmap had matched (from top to bottom) and processed:

! model         layout              =       symbols
  [...]
  *             *                   =       pc+%l(%v)
! model                             =       symbols
  *                                 =       +inet(evdev)
! option                            =       symbols
  [...]
  grp:win_switch                    =       +group(win_switch)

It should now not be hard to deduce the xkb_symbols include line quoted above, starting from the setxkbmap command line. I ll reproduce both for you for convenience:

setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch
xkb_symbols     include "pc+us(intl)+inet(evdev)+group(win_switch)"    ;

A short note about the syntax here: group(win_switch) in the symbols column simply references the xkb_symbols stanza named win_switch in the symbols file group (/usr/share/X11/xkb/symbols/group). Thus, the rules file maps parameters to sets of snippets to include, and the output of setxkbmap applies those rules to create the xkb_keymap output, to be processed by xkbcomp (which setxkbmap invokes implicitly, unless the -print argument was given on invocation). It seems that for a criteria (option, model, layout, ) to be honoured, it has to appear in the corresponding listing file, evdev.lst in this case. There is also evdev.xml, but I couldn t figure out its role.

Attaching symbols to keys I ended up creating a symbols file of reasonable size, which I won t discuss here. Instead, let s solve the following two tasks for the purpose of this document:

1. Make the Win-Hyphen key combination generate an en dash ( ), and Win-Shift-Hyphen an em dash ( ).
2. Let the Caps Lock key generate Mod4, which can be used e.g. to control the window manager.

To approach these two tasks, let s create a symbols file in ~/.xkb/symbols/xkbtest and add two stanzas to it:

partial alphanumeric_keys
xkb_symbols "dashes"  
  key <AE11>  
    symbols[Group2] = [ endash, emdash ]
   ;
 ;
partial modifier_keys
xkb_symbols "caps_mod4"  
  replace key <CAPS>  
    [ VoidSymbol, VoidSymbol ]
   ;
  modifier_map Mod4   <CAPS>  ;
 ;

Now let me explain these in turn:

1. We used the option grp:win_switch earlier, which told xkb that we would like to use the windows keys to switch to group 2. In the custom symbols file, we now simply define the symbols to be generated for each key, when the second group has been selected. Key <AE11> is the hyphen key. To find out the names of all the other keys on your keyboard, you can use the following command:

   xkbprint -label name $DISPLAY -   gv -orientation=seascape -
   
   

   I had to declare the stanza partial because it is not a complete keyboard map, but can only be used to augment/modify other maps. I also declared it alphanumeric_keys to tell xkb that I would be modifying alphanumeric keys inside it. If I also wanted to change modifier keys, I would also specify modifier_keys. The rest should be straight-forward. You can get the names of available symbols from keysymdef.h (/usr/include/X11/keysymdef.h on a Debian system, package x11proto-core-dev), stripping the XK_ prefix.
2. The second stanza replaces the Caps Lock key definition and prevents it from generating symbols (VoidSymbol). The important aspect of the second stanza is the modifier_map instruction, which causes the key to generate the Mod4 modifier event, which I can later use to bind key combinations for my window manager (awesome).

The easiest way to verify those changes is to put the setxkbmap -print output of the keyboard map you would like to use as a baseline into ~/.xkb/keymap/xkbtest, and append snippets to be included to the xkb_symbols line, e.g.:

"pc+us(intl)+inet(evdev)+group(win_switch)+xkbtest(dashes)+xkbtest(caps_mod4)"

When you try to load this keyboard map with xkbcomp, it will fail because it cannot find the xkbtest symbol definition file. You have to let the tool know where to look, by appending a path to its search list (note the use of $HOME instead of ~, which the shell would not expand):

xkbcomp -I$HOME/.xkb ~/.xkb/keymap/xkbtest $DISPLAY

You can use xev to verify the results, or just type Win-Hyphen into a terminal; does it produce ? By the way, I found xev much more useful for such purposes when invoked as follows (thanks to Penny for the idea):

xev   sed -ne '/^KeyPress/,/^$/p'

Unfortunately, xev does not give any indication of which modifier symbols are generated. I have found no other way to verify the outcome, other than to tell my window manager to do something in response to e.g. Mod4-Enter, reloaded it, and then tried it out.

Rules again, and why I did not use them in the end Once I got this far, I proceeded to add option-to-symbol-snippet mappings to the rules file, and added each option to the listing file too. A few bugs [[!debbugs 524512 desc=later]], I finally had setxkbmap spit out the right xkb_keymap and could install the new keyboard map with xkbcomp, like so:

setxkbmap -I$HOME/.xkb [...] -print   xkbcomp -I$HOME/xkb - :0

I wrote a small script to automatically do that at the start of the X session and could have gone to play outside, if it hadn t been for the itch I felt due to the entire rule file stored in my configuration. I certainly did not like that, but I could also not find a way to extend a rule file with additional rules. When I looked at the aforementioned script again, it suddenly became obvious that I was going a far longer path than I had to. Even though the rule system is powerful and allows me to e.g. automatically include symbol maps to remap keys on my Thinkpad, based on the keyboard model I configured, the benefit (if any) did not justify the additional complexity. In the end, I simplified the script that loads the keyboard map, and defined a default xkb_keymap, as well as one for the Thinkpad, wich I identify by its fully-qualified hostname. If a specific file is available for a given host, it is used. Otherwise, the script uses the default.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

You can now try the “Nouveau” free software nVidia video drivers from Debian experimental. If you would like to try them:

• Ensure you are using Debian sid.
• Add experimental sources to your /etc/apt/sources.list.
• Run:
  • sudo apt-get update
  • sudo m-a update
  • sudo m-a a-i drm
  • sudo apt-get install xserver-xorg-video-nouveau
• Edit your /etc/X11/xorg.conf and specify the nouveau driver in the Device section.
• Restart X. You will need to remove the binary nvidia kernel module.

Editing your xorg.conf may be as simple as the replacing nvidia or nv with nouveau; nouveau won’t be chosen automatically over nv yet. If your xorg.conf has collected a lot of cruft over the years, see this wiki page for some pointers on what you can remove. For the status of the drivers with your particular card, please see upstream’s compatibility matrix. My experience has been positive; I have been using them for about two months on my dual-head 8600GT (NV50) setup with only a few small issues and a generally superior Gnometris experience. Some notes:

• If you find bugs (unrelated to the packaging), please report the problem upstream and not in the Debian bug tracker.
• At request of upstream, we are not providing 3D support. Please do not ask for it, as a wontfix tag often offends.
• Bonus points are awarded for removing the non-free nVidia driver; although installation of xserver-xorg-video-nouveau will remove nvidia-glx, purging nvidia-kernel-common and nvidia-kernel-source should remove all the module-assistant generated kernel modules. rms would be proud.

Many thanks to:

• Matthew Johnson (mjj29) for uploading.
• Julien Cristau (jcristau) for advice.
• Christopher Halse Rogers (ROAF) for his Ubuntu packages.
• The rest of the XStrikeForce, who do rather a lot of work you don’t really notice.

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.

The radeonhd xorg driver recently gained full RandR 1.2 support, I’ve tested it out moments ago and it works. It just works. (DIE fglrx, DIE DIE DIE). Joy and happiness today, and thanks to Julien CRISTAU, it’s even packaged in experimental (I owe you a beer, obviously). Now, given that we now have a working video driver, and an opensource one even, let’s think about implementing something in pommed for that nice little video switch button that’s on F7. I don’t really know how to go about implementing the video switch feature. Either I’m doing it in pommed in the form of a shell script that will have to “steal” the user’s X session, or I’m doing it in the frontends, which will obviously be a bit easier. Which raises another question: shell script around xrandr, or RandR support in the frontends? That latter option doesn’t look terribly appealing to me, as it involves quite some code that will have to be maintained up-to-date wrt RandR evolutions, and that also means being backward-compatible with older RandR versions etc. So it’s probably going to be only a simple shell script, executed by the frontend. I’d like more input on this, so if you have a take on how it should/could be done, please drop me a mail. Otherwise you’ll have to live with whatever I’ll come up with ;-)

Today was a strange day. We are preparing our holiday trip to Sicily but had a full day at home, meant for packing and the like. Indeed, packing was done in a few hours this morning and I ended up....hacking on D-I. For whatever reason, I came back on the plans we have, among the D-I team, to switch to console-setup for console handling. Something already done in Ubuntu and which brings, for instance and if I'm correct, the benefit of having the same keyboard maps for X and the console. So, first, I summarized the floating ideas in a wiki page. Then I worked on a few possible modifications to "localechooser", the D-I component that allows users to choose their language/country/locale and which needs modifications for console-setup. That lead me to produce an experimental image of D-I netboot for i386 and asked translators for some testing. MJ Ray noticed the call for testing and asked Esperanto translators for some testing, which Serge Leblanc did...and reported a nasty bug, later confirmed by Damyan Ivanov, then investigated by Anton Zinoviev, then digged a little more by me again, then advised by Rapha l Hertzog and Julien Cristau on #debian-devel-fr...and lead to an RC bug reported against....perl base. All this, of course, was completely unplanned as of this morning. This is probably one of the reasons that make me enjoy free software development.

I've been back from Edinburgh for a few days, but this is the first real chance I've had to sit down and write a little bit about it. I'll preface this blog post by saying that my first Debconf was probably the best single week of my entire life. Yeah, it was that awesome.

I won't talk about all the stuff that happened, because that would just take too long. The most important thing was that I got to see a number of old friends again and spend more time with them in one run than ever before. That alone was really enormous for me. On top of that was the pleasure of finally meeting so many people in person. I met a few XSF members finally, including Julien Cristau, my partner in crime. There's no way I could possibly list everyone that I'm so thankful to have finally met. There was one very memorable evening in the night venue where it was largely the same crowd who's usually in #debian-devel when I'm on, and we all just couldn't stop cracking jokes and laughing (not to mention ITP'ing absurd programs). There was another night when Old World Cambridge collided with New World Cambridge, and much Pimm's was had by (almost) all. There was staying up until 5 in the morning and stumbling back to the hostel in the dawn to try and get some sleep before running back to the conference. The most delightful thing about all this was that so many people I already knew and loved were there, and everyone who I hadn't met in person before turned out to be even better in real life. It was like a week of the purest joy.

I also got the privilege of giving my talk and BoF to fairly full audiences, particularly the former. The BoF was on maintaining packages with git. I didn't expect more than 10 people to show, but more than 5 times that did express interest, so many that they moved it to the main lecture hall instead of the small discussion room that it was going to be in originally. I hadn't really planned out how to handle an audience like that, and while I managed to get other people in the audience talking (thanks in particular to Madduck, MadCoder, and keithp for adding so much to the discussion) I felt like I had to fumble through a lot of it. That's the nature of a BoF I guess. I also gave a talk on my plans for the XSF for the Lenny release. I'll talk about that stuff in future blog posts (some of which are overdue) but I will say that it was surprisingly well attended given that it was scheduled for 9:45 am after one of the usual nights of drinking and hacking until dawn.

I have to echo others and give a big thank you to the organizers. You guys did a great job, and persevered in the face of adversity (read: cowgate) and really made a great conference out of it. I learned a lot, laughed even more, and drank even more than that and I can't wait to do it again.

I think people are still a little euphoric over the etch release, but I'd like to let people know why Xorg 7.2 is still in experimental. Julien Cristau has done a ton of the grunt work, uploading all the usual library updates to unstable, and they're looking good so far, so at least that part is in place. The problem relates to the fact that the XSF wants to push forward with moving from Xlib to XCB. XCB represents a significant improvement over the traditional Xlib, and it's important that we work to nurture and standardize it. The good news about XCB is that most people transitioned over to it without any noticeable issues. Everything pretty much seems to work transparently, which is testament to the amount of care and time the XCB team has put in to creating it over the past several years.

But now for the bad news: there's some regressions, and they're almost all in non-free software. The biggest issue is this one: XCB will break java. You can work around it in older versions of java (as documented in that bug report) but in the newer ones you can't do much of anything. The XCB team and XSF (there's actually a fair bit of overlap there, because the XCB guys are Debian developers and I consider them XSF team members in that sense) were trying to hash out a solution to the problem. We're still working on it, but it represents the problems with depending heavily on non-free software in a free software context. Hopefully Sun will actually try to respond to the issue and release a java update that works with XCB. We can hack around the problem by disabling some checks in XCB, but the problem is really with buggy software, and we want to catch and fix those bugs. Essentially though, I'm not willing to break java in unstable so we're at something of a standstill.

In addition, there's a bug with a bit of proprietary Nvidia code. The XCB guys have a handle on that one, and think they can patch XCB itself to work around it, so hopefully that's a non-issue. Finally, some number of users have reported major performance degredation using XCB in some configurations. The XCB guys were actively going after that bug as well yesterday, so hopefully that'll be resolved soon too.

So that's where we're at. The server is looking good, and thanks to Julien and Drew Parsons we've got the latest X server release candidate and new drivers sitting in experimental, complete with the new (intel-only right now) randr 1.2 hotness, so if you want it, you know where to get it. I've finally begun my small contributions to the having a fully automagic configuring X server in experimental as well, but I'll blog about that when I reach my first milestone.

Julien Cristau and I have finished putting Xorg 7.2 in to experimental, so have at it! Julien did most of the work on this release, including the server and libs. The transition to git appears to be paying off already, as we're all moving towards running the bleeding edge stuff mainly because it's so easy to do now. This should give us the ability to take a more active role in upstream development. I've already sorta taken on responsibility for some of the upstream documentation (don't ask me how that happened) but now that things are moving I'll be looking to do work in the code as well. I wouldn't be surprised if other XSF members start to do the same.